Size Change: 0 B

Total Size: 1.69 MB

_{compressed-size-action}

This pull request changed or added PHP files in previous commits, but none have been detected in the latest commit.

Thank you! ❤️

I spent some time thinking about the problem of colliding assets and I think we should explore changing the output directories of script and module assets. This could mean things like CSS duplication, but I think we're unlikely to have both script and viewModule assets that load on a site's frontend and expect to share CSS assets. If they do, some duplicated CSS assets seem preferable to potentially broken assets.

That should make the cleaning strategies simpler as builds would have more control over their output directories.

I think something like this would be good, but I do want to do some testing:

build/
  script/editor.js
  script/…other-assets-from-script-build
  module/view.js
  render.php
  block.json
  …other-copied-assets

That doesn't need to block review of this PR, it can be landed and we can iterate on the output strategy.

viewModule probably needs a dev note, but we'll cover that as part of #57437 or maybe a broader module announcement.

I spent some time thinking about the problem of colliding assets and I think we should explore changing the output directories of script and module assets. This could mean things like CSS duplication, but I think we're unlikely to have both script and viewModule assets that load on a site's frontend and expect to share CSS assets. If they do, some duplicated CSS assets seem preferable to potentially broken assets.

That should make the cleaning strategies simpler as builds would have more control over their output directories.

I think something like this would be good, but I do want to do some testing:

build/
  script/editor.js
  script/…other-assets-from-script-build
  module/view.js
  render.php
  block.json
  …other-copied-assets

That doesn't need to block review of this PR, it can be landed and we can iterate on the output strategy.

I put together a proposal in #57761 that outputs different assets to different directories, but I'm not completely happy with it.

I now think that there is less likelihood of assets colliding because assets are named based on files in the src directory. Different assets can't have the same name because they would be the same src file (technically they probably could, but that's unlikely to happen in reality at this time).

Let's see what happens while folks use module builds and whether there's a problem in practice.

How to change the previously working webpack additional config?

I mean I was using something like this to add additional entrypoint:

const defaultConfig = require( '@wordpress/scripts/config/webpack.config' );
const path = require( 'path' );

module.exports = {
	...defaultConfig,
	entry: {
		...defaultConfig.entry(),
		navigation: [
			path.resolve( __dirname, 'src', 'navigation', 'index.js' ),
		],
	},
	output: {
		filename: '[name].js',
		path: path.resolve( process.cwd(), 'build' ),
		clean: true,
	},
};

Now this is not working anymore. I got the error TypeError: defaultConfig.entry is not a function.

Can you please explain how to handle module compilation with multiple entrypoint?

How to change the previously working webpack additional config?
…
Can you please explain how to handle module compilation with multiple entrypoint?

Thanks for the report @Tropicalista. These changes were not intended the modify the webpack config (unless you've opted in to experimental module compilation). I'll investigate.

Can you please explain how to handle module compilation with multiple entrypoint?

I'm sorry, I missed that this was for module compilation, so the build is being run with the --experimental-modules flag.

@Tropicalista With experimental module compilation we don't support using the webpack configuration directly for extension like in your example. Module compilation via this package is experimental and we need to be able to change or remove the module configuration. In the future, module compilation may not even be handled via webpack.

The main issue for discussing this module integration is #57492. Not considering the module webpack config to be public is one of the decisions we made at least for this first version:

No webpack config for module compilation will be considered public at this time for consumers to extend.